Default Profiles

Many of our partners face challenges when it comes to capturing the expected departure time of a driver and the required energy for charging. Some have implemented creative solutions—such as mobile applications, email integrations, or even on-site tables at charging locations—where drivers can enter this information directly.

However, a significant number of partners prefer to rely on “default profiles” for specific locations. In practice, this means:

Applying a single profile to an entire parking lot, or
Associating specific charging stations with distinct profiles to give drivers more flexibility.

What Is a Default Profile?

A default profile is a predefined set of overrides that can be configured either in the portal or via our API. Each profile contains values for:

estimatedDepartureTime
requestedMinEnergy
requestedMaxEnergy

For a full list of fields and their descriptions, please refer to the API documentation.

When a transaction is created, you can optionally include a profile_id in its payload. If provided, our system will fetch the corresponding profile and determine how to set each of the three fields as follows:

No Values Provided
If estimatedDepartureTime, requestedMinEnergy, and requestedMaxEnergy are all undefined in the transaction payload, we will use the values from the associated profile.
Some or All Values Provided
For any field that is defined in the payload, we will always use the payload’s value—regardless of whether it exceeds the profile’s corresponding value. For any field that is undefined, we will fill it from the profile.

Example Scenarios

Below we show a couple of example scenarios. Be careful with these examples, as the transaction payloads and profile payloads are not complete—they serve only to explain how overrides occur. For a fully detailed payload, please refer to the API documentation.

Scenario A (No Values in Payload)
- Partial Transaction payload:
```
{
  ...,
  "profile_id": "abc123",
  ...
}
```
- Profile abc123 defines:
  - estimatedDepartureTime: "2025-06-04T20:00:00Z"
  - requestedMinEnergy: 30000
  - requestedMaxEnergy: 50000
- Result:
  - All three fields are populated from Profile abc123 (20:00 on June 4, 30 kWh, 50 kWh).
Scenario B (All Values Provided in Payload)
- Partial Transaction payload:
```
{
  ...,
  "profile_id": "abc123",
  "estimatedDepartureTime": "2025-06-03T18:00:00Z",
  "requestedMinEnergy": 20000,
  "requestedMaxEnergy": 40000,
  ...
}
```
- Profile abc123 defines:
  - estimatedDepartureTime: "2025-06-04T20:00:00Z"
  - requestedMinEnergy: 30000
  - requestedMaxEnergy: 50000
- Result:
  - Use exactly the payload values: 18:00 on June 3 (even though it’s earlier than the profile), 20 kWh, and 40 kWh.
Scenario C (Partial Values Provided)
- Partial Transaction payload:
```
{
  ...,
  "profile_id": "abc123",
  "estimatedDepartureTime": "2025-06-03T18:00:00Z",
  ...
}
```
- Profile abc123 defines:
  - estimatedDepartureTime: "2025-06-04T20:00:00Z"
  - requestedMinEnergy: 30000
  - requestedMaxEnergy: 50000
- Result:
  - estimatedDepartureTime is taken from the payload: "2025-06-03T18:00:00Z".
  - requestedMinEnergy and requestedMaxEnergy are undefined in the payload, so they are filled from the profile (30 kWh and 50 kWh).

What Is a Default Profile?​

Example Scenarios​

What Is a Default Profile?

Example Scenarios